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Abstract 

We propose a new extended format to represent constraint networks 
using XML. This format allows us to represent constraints denned either in 
C/3 extension or in intension. It also allows us to reference global constraints. 

| O | Any instance of the problems CSP (Constraint Satisfaction Problem), 

QCSP (Quantified CSP) and WCSP (Weighted CSP) can be represented 
using this format. 

^ A subset of this format will be used for the third international com- 

{N| petition of CSP solvers which will be held during summer 2008 (deadline: 

\Q May 10, 2008). 
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£Sj The release of this document is January 15, 2008. 
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1 Introduction 

The Constraint Programming (CP) community suffers from the lack of a stan- 
dardized representation of problem instances. This is the reason why we propose 
an XML representation of constraint networks. The Extensible Markup Lan- 
guage (XML) [TH] is a simple and flexible text format playing an increasingly 
important role in the exchange of a wide variety of data on the Web. The objec- 
tive of the XML representation is to ease the effort required to test and compare 
different algorithms by providing a common test-bed of constraint satisfaction 
instances. 

One should notice that the proposed representation is low-level. More pre- 
cisely, for each instance, domains, variables, relations (if any), predicates (if 
any) and constraints are exhaustively defined. The current format should not 
be confused with powerful modelling language such as the high-level proposals 



dedicated to mathematical programming - e.g. AMPL (http : //www . ampl . com) 
and GAMS (http://www.gams.com) - or dedicated to constraint programming^] 
- e.g. OPL [lfj , EaCL [16 , NCL [13], ESRA [3J, Zinc [B] and ESSENCE [5^ 
Nevertheless, we also project to extend this format in a near future to take into 
account higher level constructs. 

In this document, we present an extension, denoted XCSP 2.1, of the format 
XCSP 2.0 which was used for the 2006 CSP solver competition. It aims at being 
a (hopefully good) compromise between readability, verbosity and structuration. 
More precisely, our objective is that the representation be: 

• readable: thanks to XML, we think that it is the case. If you want to 
modify an instance by hand, you can do it without too many difficulties 
whereas it would be almost impossible with a tabular format. Only a few 
constructions require an a-priori knowledge of the format. 

• concise: with the abridged version which doesn't use systematically XML 
tags and attributes, the proposed representation can be comparable in 
length to one that would be given in tabular format. This is important, 
for example, to represent instances involving constraints in extension. 

• structured: because the format is based on XML, it remains rather easy 
to parse instances. 

Roughly speaking, we propose two variants of this format: 

• a fully-tagged representation, 

• an abridged representation. 

The first representation (tagged notation) is a full XML, completely struc- 
tured representation which is suitable for using generic XML tools but is more 
verbose and more tedious to write for a human being. The second representa- 
tion (abridged notation) is just a shorthand notation of the first representation 



1 Remark that the specification language Z | |http : //vl .users ■ org| has also been used to 
build nice (high-level) problem models |15j 
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which is easier to read and write for a human being, but less suitable for generic 
XML tools. 

These two representations are equivalent and this document details the trans- 
lation of one representation to another. Automatic tools to convert from one 
representation to another will be made available, and parsers will accept the two 
representations. This will allow human beings to use the shorthand notation to 
encode an instance while still being able to use generic XML tools. 

2 Basic Components 

This section describes how the most common kinds of information are repre- 
sented in this XML format. This section only details the general data struc- 
tures that are used in the description of instances. The way these structures 
are used to represent an instance is presented in the other sections of this doc- 
ument. As mentioned in the introduction, we present two representations for 
each structure. The first one is fully-tagged and the second one is abridged. 

2.1 Identifiers and Integers 

First, let us introduce the syntax of identifiers and integers. An identifier has to 
be associated with some XML elements, usually under the form of an attribute 
called name. An identifier must be a valid identifier according to the most 
common rules (start with a letter or underscore and further contain letters, 
digits or underscores). More precisely, identifiers and integers are defined (in 
BNF notation) as follows: 

<identifier> ::= <letter> I "_" { <letter> I <digit> I "_" } 
<integer> : := [ "+" I "-"] <digit> {<digit>} 
<letter> : := "a" . . "z" I "A" . . "Z" 
<digit> : := "0". ."9" 

Of course, identifiers are case-sensitive. 

2.2 Separators 

2.2.1 Tagged notation 

For the tagged version, we do not need to use any specific separator since the 
document is fully structured. 

2.2.2 Abridged notation 

For the abridged version, we sometimes need to employ separators. They are 
defined as follows: 

<whitespace> ::= " " I "\t" | "\n" I "\r" 
<separator> ::= <whitespace> I { <whitespace> } 
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2.3 Constants 

Different kinds of constant can be used in the encoding of a CSP instance. 

2.3.1 Tagged notation 

Boolean constants are written using two special elements: <true/> and <f alse/>. 
Integer constants are written inside a <i> clement (e.g. <i>19</i>). 
Real constants are written inside a <r> element (e.g. <r>19.5</r>). 

2.3.2 Abridged notation 

Wherever it is legal to have a numerical constant, its value can be written 
directly without the enclosing tag (e.g. 19, 19.5). 19 is considered as an integer 
constant. 

To avoid introducing reserved keywords, Boolean constants (<true/> and 
<f alse/>) cannot be abridged. 

2.4 Intervals 

2.4.1 Tagged notation 

Intervals are represented by a <interval> clement with two attributes: min and 
max. The min represents the minimal value of the interval (the lower bound) 
and the max attribute the maximal value (the upper bound). For example, 
<interval min="10" max="13"/> corresponds to the set {10,11,12,13}. 

2.4.2 Abridged notation 

To represent an interval, on has just to write two constants (of the same type) 
separated by the sequence For example, 10. .13 corresponds to the set of 

integers {10,11,12,13}. 

2.5 Variables 

Several constructs in the format have to reference variables. For simplicity, we 
consider here that the term variable refers to both effective and formal param- 
eters of functions and predicates. 

2.5.1 Tagged notation 

The reference to a variable is represented by a <var> clement with an empty 
body and a single attribute name which provides the identifier of the vari- 
able. For example, a reference to the variable XI is represented by <var 
name="Xl"/>. 
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2.5.2 Abridged notation 

Wherever it is legal to have a <var name=" identifier "/> element, this ele- 
ment can be replaced equivalently by identifier . For example, XI and <var 
name="Xl"/> are two legal and equivalent ways to refer to the variable XI. 

2.6 Formal parameters 

A predicate or function in this XML format must first define the list of its formal 
parameters (with their type). Then, these formal parameters can be referenced 
with the notations defined in section 12.51 

In both tagged and abridged representations, formal parameters are defined 
in the body of a <parameters> clement. 

2.6.1 Tagged notation 

In the tagged notation, each formal parameter is defined by a <parameter> 
element with two attributes. The attribute name defines the formal name of 
the parameter and the attribute type defines its type. For example, <parameter 
name="X0" type="int"> defines a parameter named XO of integer type. 

2.6.2 Abridged notation 

Wherever it is legal to have a <parameter> element, a formal parameter can be 
written in abridged notation by its type followed by whitespace followed by the 
parameter name (as in C and Java programming language). Consecutive pa- 
rameters must be separated by whitespace. For example, int XO is the abridged 
representation of <parameter name="X0" type="int">. 

The syntax of the formal parameters list is described by the following gram- 
mar (in BNF notation): 

<f ormalParameters> : := [<f ormalParametersList>] 
<f ormalParametersList> ::= <f ormalParameter> 

I <f ormalParameter> <separator> <f ormalParametersList> 
<f ormalParameter> ::= <type> <separator> <identif ier> 
<type> : := "int" 

2.7 Lists 

A list is an array of (possibly heterogeneous) objects. The order of objects in 
the list is significant (but this order may be deliberately ignored when needed) . 

2.7.1 Tagged notation 

A list is represented by a <list> clement with all members of the list given in 
the body of the element. For example, a list containing the integers 1, 2 and 
the Boolean value true is represented by: 

<list> <i>K/i> <i>2</i> <true/> </list> 
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2.7.2 Abridged notation 

Wherever it is legal to have a list element, the opening square brace is defined 
as a synonym of <list> and the closing square brace is defined as a synonym 
of </list>. A separator is used between two elements of the list. Whitespace 
can be found before and after a square brace. 
[1 2 <true/>] 

2.8 Matrices 

Vectors are represented as lists, 2-dimensions matrices are represented as lists of 
vectors, 3-dimensions matrices are represented as lists of 2-dimensions matrices 
and so on. To improve readability, 2-dimcnsions matrices are represented as 
lists of lines of coefficients. 

[1 2 3] 
[ 

[1 2 3] 
[0 1 2] 
[0 1] 

] 

2.9 Dictionaries 

A dictionary is an associative array that maps a key to a value. In other words, 
it is an array of <key,value> pairs. A key is a name which references a value in 
the data structure. A notation common to a number of languages to access the 
value corresponding to a key A: in a dictionary d is d[k\. In a sense, a dictionary 
is a generalization of an array: indices in (classical) arrays must be contiguous 
integers while keys in a dictionary can be arbitrary names. A dictionary can also 
be seen as a generalization of the notion of structures (struct in C/C++) and 
records (Pascal) . A record with n fields /i , . . . , /„ can be seen as a dictionary 
containing the n keys /i , . . . , f n and the corresponding values. A dictionary is 
an extension of a record since new keys can be added to a dictionary while a 
record usually has a fixed list of fields. Each pair <key,value> in a dictionary 
is called an entry in that dictionary. 

A function which accepts a dictionary as parameter can decide that some 
keys must be present in the dictionary and that some others keys are optional. 
This provides a simple way to support optional parameters. When a key is 
missing in a dictionary, it is considered that there is no corresponding value. 
The special tag <nil/> is another way to specify explicitly that a key has no 
corresponding value. This special value corresponds to the null value in SQL. 
Omitting a key k from a dictionary or defining that key k corresponds to value 
<nil/> are equivalent ways of associating no value to key k. 
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The order of keys in a dictionary is not significant. A dictionary may contain 
no key at all. A dictionary can be associated to a key in a given dictionary (in 
other words, dictionaries may be contained in a dictionary). 

2.9.1 Tagged notation 

An entry of a dictionary that associates a value v with key k is encoded by an 
element <entry> with a single attribute key with value k and a body containing 
the value v. <entry key="k">v</entry> 

A dictionary is defined by a <dict> element with all entries of the dictionary 
given inside the body: <dict><entry key="namel">valuel</entry> <entry 
key="name2">value2</entry></dict>. The body of this element cannot con- 
tain other elements than dictionary entries. 

2.9.2 Abridged notation 

Several notations are already used in different languages to associate a key with 
a value in an associative array (key => value in PHP and Perl, /key value in 
PostScript and PDF,...). Since the character > is a reserved character in XML, 
we use the PostScript notation. 

A dictionary in abridged notation starts by a opening curly brace followed 
by a list of entries and is ended by a closing curly brace. Each entry is written 
as a key immediately preceded by a slash (no space between the slash and the 
key), whitespace and the value corresponding to this key. Whitespace can be 
found before and after a curly brace. For example: 

{/namel value2 /name2 value2} 

2.9.3 Conventional order 

In some cases (e.g. when a function expects a dictionary with a given set of keys) , 
a conventional order can be associated with a dictionary. This conventional 
order specifics a default order of keys which can be used to further shorten the 
notations. When the conventional order of keys can be known from the context, 
a dictionary can be written in abridged notation by opening a curly brace, listing 
the values of each key which is expected in the dictionary and closing the curly 
brace. The absence of a slash following the opening curly brace identifies a 
dictionary represented in conventional order (note however that white space is 
allowed between the opening curly brace and the first slash). 

In this context, there must be as many values inside the curly braces as the 
number of keys in the conventional order. To assign no value to a given key, the 
special value <nil/> must be used. 

For example, the coordinates of a point of a plane may be represented by a 
dictionary containing two keys x and y. The point at coordinates (2, 5) can be 
represented by several notations. We can have: 

<dict> 

<entry key="x"Xi>2</ix/entry> 
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<entry key="y"xi>5</ix/entry> 
</dict> 

or: 

<dict> 

<entry key="y"Xi>5</ix/entry> 
<entry key="x"Xi>2</ix/entry> 
</dict> 

or: 

{/x 2 /y 5} 
or: 

{/y 5 /x 2} 

or: 

{ 

/x 2 

/y 5 

} 

When a conventional order is fixed which indicates that key x is given before 
key y, the same dictionary can be written by: 

{2 5} 

2.10 Tuples 

Here, we consider a tuple as being a sequence of objects of the same type. For 
example, (2,5,8) is a tuple containing three integers. 

2.10.1 Tagged notation 

A tuple is represented by a <tuple> element with all members of the tuple given 
in the body of the clement. For example, the tuple (2, 5, 8) is represented by: 
<tuple> <i>2</i> <i>5</i> <i>8</i> </tuple> 

2.10.2 Abridged notation 

For the abridged variant, the members of any tuple are written directly within 
the enclosing tag. However, if we have two successive tuples (i.e. . . . </tuple> 
<tuple> . . . ), we use the character '|' as a separator between them. For exam- 
ple, the representation of a sequence of binary tuples takes the form (in BNF 
notation) : 
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<binaryTupleSequence> ::= <binaryTuple> I <binaryTuple> "I" <binaryTupleSequence> 
<binaryTuple> ::= <integer> <separator> <integer> 

For ternary relations, one has just to consider tuples formed from 3 values, 
etc. For example, a list of binary tuples is: 

1|0 3|1 2|1 3|2 0|2 1|3 1 

while a list of ternary tuples is: 

1|0 2 111 111 2 0|2 1 1|2 2 2 

2.11 Weighted Tuples 

It may be interesting (e.g. see the WCSP framework [IT]) to associate a weight 
(or cost) with a tuple or a sequence of tuples. 

2.11.1 Tagged notation 

We then just have to enclose this tuple (these tuples) within a <weight> element 
which admits one attribute value. This attribute must be an integer or the 
special value "infinity" . For example, if a weight equal to 10 must be associated 
with the tuple (2,5,8), we obtain: 

<weight value="10"> <tuple> <i>2</i> <i>5</i> <i>8</i> </tuple> 
</weight> 

Notice that it is possible to directly associate the same weight with several 
tuples. 

2.11.2 Abridged notation 

In abridged notation, each tuple can be given an explicit cost by prefixing it 
with its cost followed by a colon character ':'. When a cost is not specified for a 
tuple, it simply means that the cost of the current tuple is equal to the cost of 
the previous one. At the extreme, only the first tuple is given an explicit cost, 
all other tuples implicitly referring to this cost. In any case, the first tuple of a 
relation must be given an explicit cost. Remark that with the abridged variant, 
it is not possible to put in the same context unweighted and weighted tuples 
(but, we believe that it is not a real problem). Finally, to associate the special 
value "infinity" with a tuple, the special element <inf inity/> must be used. 

For example, let us consider the following "classical" list of binary tuples: 

1|0 3|1 2|1 3|2 0|2 1|3 1 

If 1 is the cost of tuples (0, 1), (0, 3), (3, 1) whereas 10 is the cost of all other 
tuples, then we can write: 

1:0 1 1 1 : 3110:1 2 1 10 : 1 3 1 10:2 0|10:2 1 1 1 : 3 1 

but also, using implicit costs: 
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1:0 1|0 3110:1 2 1 1 3 I 2 I 2 111:3 1 

This example may also be written equivalently on several lines: 

1: 1|0 3| 

10: 1 2|1 3|2 0|2 1| 

1: 3 1 

Note that using the abridged representation to associate costs with tuples 
allows us to save a large amount of space. 

3 Representing CSP instances 

In order to avoid any ambiguity, we briefly introduce constraint networks. A 
constraint network consists of a finite set of variables such that each variable X 
has an associated domain dom(X) denoting the set of values allowed for X, and 
a finite set of constraints such that each constraint C has an associated relation 
rel(C) denoting the set of tuples allowed for the variables scp(C) involved in C. 
A solution to a constraint network is the assignment of a value to each variable 
such that all the constraints are satisfied. A constraint network is said to be 
satisfiable if it admits at least a solution. The Constraint Satisfaction Problem 
(CSP), whose task is to determine whether or not a given constraint network is 
satisfiable, is NP-hard. A constraint network is also called a CSP instance. For 
an introduction to constraint programming, see for example pJ[T]. 

Each CSP instance is represented following the format given in Figure [l] 
where q, n, r, p and e respectively denote the number of distinct domains, the 
number of variables, the number of distinct relations, the number of distinct 
predicates and the number of constraints. Note that q < n as the same domain 
definition can be used for different variables, r < e and p < e as the same 
relation or predicate definition can be used for different constraints. Thus, each 
instance is defined by an XML element which is called <instance> and which 
contains four, five or six elements. Indeed, it is possible to have one instance 
defined without any reference to a relation or/and to a predicate. Then, the 
elements <relations> and <predicates> may be missing (if both are missing, 
it means that only global constraints are referenced). 

Each basic element (<presentation>, <domain>, <variable>, <relation>, 
<predicate> and <constraint>) of the representation admits an attribute 
called name. The value of the attribute name must be a valid identifier (as 
introduced in the previous section). In the representation of any instance, it is 
not possible to find several attributes "name" using the same identifier. 

Remark 1 In the body of any element of the document, one can insert an 
<extension> element in order to put any information specific to a solver. 

3.1 Presentation 

The XML clement called <presentation> admits a set of attributes and may 
contain a description (a string) of the instance: 
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<instance> 

presentation 

name = 'put here the instance name' 

format = 'XCSP 2.1' > 
Put here the description of the instance 
</presentation> 

<domains nbDomains='q'> 
<domain 

name = 'put here the domain name' 
nbValues = 'put here the number of values' > 
Put here the list of values 
</domain> 

</domains> 

<variables nbVariables='n'> 
<variable 

name = 'put here the variable name' 
domain = 'put here the name of a domain' 

/> 

</variables> 

<relations nbRelations='r'> 
<relation 

name = 'put here the name of the relation' 
arity = 'put here the arity of the relation' 
nbTuples = 'put here the number of tuples' 
semantics = 'put here either supports or conflicts' > 
Put here the list of tuples 
</relation> 

</relations> 

<predicates nbPredicates='p'> 
<predicate 

name = 'put here the name of the predicate' > 
<parameters> 

put here a list of formal parameters 
</parameters> 
<expression> 

Put here one (or more) representation of the predicate expression 
</expression> 
</predicate> 

</predicates> 

Constraints nbConstraints= ' e ' > 
<constraint 

name = 'put here the name of the constraint' 
arity = 'put here the arity of the constraint' 
scope = 'put here the scope of the constraint' 
reference = 'put here the name of a relation, a 
predicate or a global constraints 

</constraint> 

</constraints> 
</instance> 



Figure 1: XML representation of a CSP instance 
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presentation 

name = 'put here the instance name' 

maxConstraintArity = 'put here the greatest constraint arity' 
minViolatedConstraints = 'the minimum number of violated constraints' 
nbSolutions = 'put here the number of solutions' 
solution = 'put here a solution' 
type = 'CSP'> 
format = 'XCSP 2.1' 
Put here the description of the instance 
</presentation> 

Only the attribute format is mandatory (all other attributes are optional 
as they mainly provide human-readable information). It must be given the 
value 'XCSP 2.1' for the current format. The attribute name must be a valid 
identifier (or the special value '?'). The attribute maxConstraintArity is of 
type integer and denotes the greatest arity of all constraints involved in the 
instance. The attribute minViolatedConstraints can be given an integer 
value denoting the minimum number of constraints that are violated by any full 
instantiation of the variables, an expression of the form 'at most k' with k being 
a positive integer or '?'. The attribute nbSolutions can be given an integer 
value denoting the total number of solutions of the instance, an expression of 
the form 'at least k' with k being a positive integer or '?'. 

For example, 

• nbSolutions = '0' indicates that the instance is unsatisfiable, 

• nbSolutions = '3' indicates that the instance has exactly 3 solutions, 

• nbSolutions = 'at least 1' indicates that the instance has at least 1 
solution (and, hence, is satisfiable), 

• nbSolutions = '?' indicates that it is unknown whether or not the in- 
stance is satisfiable, 

The attribute solution indicates a solution if one exists and has been found. 
The type attribute indicates the kind of problem described by this instance. It 
should be set to 'CSP' for a constraint satisfaction problem, 'QCSP' for a quan- 
tified CSP and 'WCSP' for a weighted CSP. For compatibility with the XCSP 
2.0 format, this attribute is optional for CSP instances (but it is strongly advised 
to use it). It is mandatory for other types of instances (QCSP, WCSP,...). 

Remark that the optional attribute maxSatisfiableConstraints, although 
still authorized, is deprecated. We encourage to use minViolatedConstraints 
instead. 

3.2 Domains 

The XML clement called <domains> admits an attribute which is called nbDo- 
mains and contains some occurrences (at least, one) of an element called 
<domain>, each one being associated with at least one variable of the instance. 
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The attribute nbDomains is of type integer and its value is equal to the num- 
ber of occurrences of the clement <domain>. Each clement <domain> admits two 
attributes, called name and nb Values and contains a list of values, as follows: 

<domain 

name = 'put here the domain name' 
nbValues = 'put here the number of values' > 
Put here the list of values 
</domain> 

The attribute name corresponds to the name of the domain and its value 
must be a valid identifier. 

The attribute nbValues is of type integer and its value is equal to the 
number of values of the domain. The content of the clement <domain> gives 
the set of integer values included in the domain. More precisely, it contains a 
sequence of integers and integer intervals. 

For the abridged variant, we have for example: 

• 1 5 10 corresponds to the set {1,5,10}. 

• 1..3 7 10. .14 corresponds to the set {1,2,3,7, 10, 11, 12, 13, 14}. 

Note that nbValues gives the number of values of the domain (i.e. the 
domain size), and not, the number of domain pieces (integers and integer inter- 
vals). 

3.3 Variables 

The XML clement called <variables> admits an attribute which is called 
<nbVariables> and contains some occurrences (at least, one) of an element 
called <variable>, one for each variable of the instance. The attribute nb Vari- 
ables is of type integer and its value is equal to the number of occurrences of 
the element <variable>. Each element <variable> is empty but admits two 
attributes, called name and domain, as follows: 

<variable 

name = 'put here the variable name' 
domain = 'put here the name of a domain' 

/> 

The attribute name corresponds to the name of the variable and its value 
must be a valid identifier. 

The value of the attribute domain gives the name of the associated domain. 
It must correspond to the value of the name attribute of a domain element. 

3.4 Relations 

If present, the XML clement called <relations> admits an attribute which is 
called nbRelations and contains some occurrences (at least, one) of an element 
called <relation>, each one being associated with at least one constraint of the 
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instance. The attribute nb Relations is of type integer and its value is equal 
to the number of occurrences of the element <relation>. 

Each element <relation> admits four attributes, called name, arity, nb Tu- 
ples and semantics, and contains a list of distinct tuples that represents either 
allowed tuples (supports) or disallowed tuples (conflicts). It is defined as follows: 

<relation 

name = 'put here the name of the relation' 
arity = 'put here the arity of the relation' 
nb Tuples = 'put here the number of tuples' 
semantics = 'put here either supports or conflicts' > 
Put here the list of tuples 
</relation> 

The attribute name corresponds to the name of the relation and its value 
must be a valid identifier. 

The attribute arity is of type integer and its value is equal to the arity of 
the relation. The attribute nbTuples is of type integer and its value is equal 
to the number of tuples of the relation. The attribute semantics can only be 
given two values: 'supports' and 'conflicts'. Of course, if the value of semantics 
is 'supports' (resp. 'conflicts'), then it means that the list of tuples correspond 
to allowed (resp. disallowed) tuples. The content of the element <relation> 
gives the set of distinct tuples of the relation. 

The representation of lists of tuples is given in Section |2.10| 

Note that an empty list of tuples is authorized by the syntax: a relation with 
an empty list of tuples is trivially unsatisfiable if its semantics is 'supports', and 
trivially satisfied if its semantics is 'conflicts'. 

3.5 Predicates 

If present, the XML element called <predicates> admits an attribute which 
is called nbPredicates and contains some occurrences (at least, one) of an 
element called <predicate>, one for each predicate associated with at least a 
constraint of the instance. The attribute nbPredicates is of type integer and 
its value is equal to the number of occurrences of the element <predicate>. 

Each element <predicate> admits one attribute, called name, and contains 
two elements, called <parameters> and <expression>. It is defined as follows: 

<predicate 

name = 'put here the name of the predicate' > 
<parameters> 

put here a list of formal parameters 
</parameters> 
<expression> 

Put here one (or several) representation(s) of the predicate expression 
</expression> 
</predicate> 

The attribute name corresponds to the name of the predicate and its value 
must be a valid identifier. 



3 REPRESENTING CSP INSTANCES 



17 



The <parameters> clement defines the list of formal parameters of the pred- 
icate. The syntax of this element is detailed is section [2l3| 

The only authorized type is for the moment 'int' (denoting integer values). 

However, in the future, other types will be taken into account: "bool", 
"string" , etc. 

The element <expression> may contain several representations of the pred- 
icate expression. 

3.5.1 Functional Representation 

It is possible to insert a functional representation of the predicate expression 
by inserting in <expression> an clement <functional> which contains any 
Boolean expression defined as follows: 

<integerExpression> ::= 

<integer> I <identif ier> 

I "neg(" <integerExpression> ") 

I "abs(" <integerExpression> ") 

I "add(" <integerExpression> ", 

I "sub(" <integerExpression> 

I "mul(" <integerExpression> 

I "div(" <integerExpression> 11 , 

I "mod(" <integerExpression> 

I "pow(" <integerExpression> 

I "min(" <integerExpression> 11 , 

I "max(" <integerExpression> 11 , 

I "if(" <booleanExpression> "," 

<booleanExpression> ::= 
"false" I "true" 
I "not(" <booleanExpression> ")" 

I "and(" <booleanExpression> "," <booleanExpression> ")" 
I "or(" <booleanExpression> "," <booleanExpression> ")" 
I "xor(" <booleanExpression> "," <booleanExpression> ")" 
I "iff(" <booleanExpression> "," <booleanExpression> ")" 
I "eq(" <integerExpression> "," <integerExpression> ")" 
I "ne(" <integerExpression> "," <integerExpression> ")" 
I "ge(" <integerExpression> "," <integerExpression> ")" 
I "gt(" <integerExpression> "," <integerExpression> ")" 
I "le(" <integerExpression> "," <integerExpression> ")" 
I "lt(" <integerExpression> "," <integerExpression> ")" 

Hence, any constraint in intension can be defined by a predicate which cor- 
responds to an expression built from (Boolean and integer) constants and the 
introduced set of functions (operators) . The semantics of operators is given by 
Table [2 

An expression usually contains identifiers which correspond to the formal 
parameters of a predicate. To illustrate this, let us consider the predicate that 
allows defining constraints involved in any instance of the queens problem. It 
corresponds to: X ^ Y A \X — Y\ ^ Z . We obtain using the functional repre- 
sentation: 



<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> ")" 

<integerExpression> "," <integerExpression> ")" 
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Operation 


Arity 


Syntax 


Semantics 


MathML 


Arithmetic (operands are 


integers 


) 


Opposite 


1 


neg(x) 


-X 


< minus > 


Absolute Value 


1 


abs(x) 


|x| 


<abs> 


Addition 


2 


add(x,y) 


x + y 


<plus> 


Substraction 


2 


sub(x,y) 


x - y 


< minus > 


multiplication 


2 


mul(x,y) 


x * y 


<times> 


Integer Division 


2 


div(x,y) 


x div y 


<quotient> 


Remainder 


2 


mod(x,y) 


x mod y 


<rem> 


Power 


2 


pow(x,y) 


xf 


<power> 


Minimum 


2 


min(x,y) 


min(x,y) 


<min> 


Maximum 


2 


max(x,y) 


max(x,y) 


<max> 


Relational (operands are integers) 


Equal to 


2 


eq(x,y) 


x = y 


<cq> 


Different from 


2 


ne(x,y) 


x ¥= y 


<ncq> 


Greater than or equal 


2 


ge(x,y) 


x > y 


<gcq> 


Greater than 


2 


gt(x,y) 


x > y 


<gt> 


Less than or equal 


2 


le(x,y) 


x < y 


<leq> 


Less than 


2 


lt(x,y) 


x < y 


<lt> 


Logic (operands arc Booleans) 


Logical not 


1 


not(x) 


—i X 


<not> 


Logical and 


2 


and(x,y) 


x A y 


<and> 


Logical or 


2 


or(x,y) 


x V y 


<or> 


Logical xor 


2 


xor(x,y) 


x e y 


<xor> 


Logical equivalence (iff) 


2 


iff(x,y) 


x <=> y 




Control 


Alternative 


3 


if(x,y,z) 


value of y if x is true, 










otherwise value of z 





Table 1: Operators used to build predicate expressions 



<predicate name="P0"> 
<parameters> 

int X int Y int Z 
</parameters> 
<expression> 
<f unctional> 

and(ne(X,Y) ,ne (abs (sub(X, Y) ) , Z) ) 
</f unctional> 
</expression> 
</predicate> 

3.5.2 MathML Representation 

MathML is a language dedicated to represent mathematical expressions. We can 
represent predicate expressions using a subset of this language. It is possible 
to insert an XML representation of the predicate expression by inserting in 
<expression> an element called <math> which contains any Boolean expression 
defined (in BNF notation) as follows: 
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<integerExpression> ::= 

"<cn>" <integer> "</cn>" 

I "<ci>" <identif ier> "</ci>" 

I "<apply> <minus/>" <integerExpression> "</apply>" 

I "<apply> <abs/>" <integerExpression> "</apply>" 

I "<apply> <plus/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <minus/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <times/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <quotient/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <rem/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <power/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <min/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <max/>" <integerExpression> <integerExpression> "</apply>" 

<booleanExpression> ::= 
"<false/>" 

I "<true/>" 

I "<apply> <not/>" <booleanExpression> "</apply>" 

I "<apply> <and/>" <booleanExpression> <booleanExpression> "</apply>" 

I "<apply> <or/> <booleanExpression> <booleanExpression> "</apply>" 

I "<apply> <xor/> <booleanExpression> <booleanExpression> "</apply>" 

I "<apply> <eq/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <neq/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <gt/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <geq/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <lt/>" <integerExpression> <integerExpression> "</apply>" 

I "<apply> <leq/>" <integerExpression> <integerExpression> "</apply>" 



For more information, See http://www.w3.org/Math Or http://www.dessci.com/en/ 

suppo rt/tutoriais/mathmi/content.htm| For example, to represent X ^ Y A \X — 
Y\ Z, we can write: 

<predicate name="PO"> 

<parameters> int X int Y int Z </parameters> 
<expression> 
<math> 
<apply> 

<neq/> <ci> X </ci> <ci> Y </ci> 
</apply> 
<apply> 

<neq/> 

<apply> 
<abs/> 

<apply> <minus/ > <ci> X </ci> <ci> Y </ci> </apply> 
</apply> 
<ci> Z </ci> 
</apply> 
</math> 
</expression> 
</predicate> 

3.5.3 Postfix Representation 

It is possible to insert a postfix representation (not fully described in this doc- 
ument) of the predicate expression by inserting in <expression> an element 
<postf ix>. For example, to represent X ^ Y A \X — Y\ ^ Z, we can write: 
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<predicate name="PO"> 
<parameters> 

int X int Y int Z 
</parameters> 
<expression> 
<postf ix> 

X Y ne X Y sub abs Z ne and 
</postf ix> 
</expression> 
</predicate> 

3.5.4 Infix Representation 

It is possible to insert an infix representation (not fully described in this doc- 
ument) of the predicate expression by inserting in <expression> an element 
<inf ix>. For example, to represent X ^ Y A \X — Y\ ^ Z, we can write (using 
a C syntax for the Boolean expression): 

<predicate name="P0"> 
<parameters> 

int X int Y int Z 
</parameters> 
<expression> 

<infix syntax="C"> 

X != Y kk abs(X-Y) != Z 
</inf ix> 
</expression> 
</predicate> 

3.6 Constraints 

The XML clement called <constraints> admits an attribute which is called 
nbConstraints and contains some occurrences (at least, one) of an element 
called <constraint>, one for each constraint of the instance. The attribute 
nbConstraints is of type integer and its value is equal to the number of oc- 
currences of the element <constraint>. 

Each element <constraint> admits four attributes, called name, arity, 
scope and reference, and potentially contains some elements: 

<constraint 

name = 'put here the name of the constraint' 
arity = 'put here the arity of the constraint' 
scope = 'put here the scope of the constraint' 
reference = 'put here the name of a relation, of 
predicate or a global constraints 

</constraint> 

The attribute name corresponds to the name of the constraint and its value 
must be a valid identifier. 

The attribute arity is of type integer and its value is equal to the arity of 
the constraint (that is to say, the number of variables in its scope). It must be 
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greater than or equal to 1. The value of the attribute scope denotes the set 
of variables involved in the constraint. It must correspond to a list of distinct 
variable names where each name corresponds to the value of the name attribute 
of a <variable> element. Variables are separated by whitespace. 

There are three alternatives to represent constraints. Indeed, it is possible 
to introduce: 

• constraints in extension 

• constraints in intension 

• global constraints 

3.6.1 Constraints in extension 

The value of the attribute reference must be the name of a relation. It means 
that it must correspond to the value of the name attribute of a <relation> 
element. The element <constraint> is empty when it represents a constraint 
defined in extension. For example: 

Constraint name="C0" scope="V0 VI" ref erence="R0" /> 

3.6.2 Constraints in intension 

The value of the attribute reference must be the name of a predicate. It means 
that it must correspond to the value of the name attribute of a <predicate> 
clement. 

The clement <constraint> contains an clement <parameters> when it rep- 
resents a constraint defined in intension. The clement <parameters> contains a 
sequence of effective parameters, each one being cither an integer or a variable 
reference (which must occur in the scope of the constraint). For the abridged 
variant, a separator is inserted between two elements. Of course, the arity of 
a predicate referenced by a constraint must correspond to the number of effec- 
tive parameters of this constraint. Also, all variables occurring in the scope of 
a constraint referencing a predicate must occur as effective parameters of this 
constraint. For example: 

Constraint name="C0" scope="V0 VI" ref erence="P0"> 

<parameters> 
VO VI 1 

</parameters> 
</constraint> 

The semantics is the following. Given a tuple built by assigning a value to 
each variable belonging to the scope of the constraint, the predicate expression 
is evaluated after replacing each occurrence of a formal parameter corresponding 
to an effective parameter denoting a variable with the assigned value. The tuple 
is allowed iff the expression evaluates to true. 

In the current version of the format, effective parameters are restricted to 
be either variables in the scope of the constraint, or integer constants. Future 
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version of the format will remove this limitation and allow any expression as an 
effective parameter. 

3.6.3 Global constraints 

The value of the attribute reference must be the name of a global constraint, 
prefixed by "global:". As the character ':' cannot occur in any valid iden- 
tifier, it avoids some potential collision with other identifiers. The name of 
global constraints is case-insensitive. Therefore, global : allDifferent and 
global : alldif f erent represent the same constraint. 

The clement <constraint> may contain an element <parameters> when it 
represents a global constraint. If present, the element <parameters> contains a 
sequence of parameters specific to the global constraint. As a consequence, the 
description of such parameters must be given for each global constraint. It is 
then clear that, for each global constraint, we have to indicate its name (the one 
to be referenced) , its parameters (and the way they are structured in XML) and 
its semantics. Below, we provide such information for four global constraints. 

Constraint weightedSum (not defined in the global constraint catalog) 

Semantics hi * Xi op b where r denotes the arity of the constraint, 

fci denotes an integer, Xi the i th variable occurring in the scope of the constraint, 
op a relational operator in {=, =/=, >,>,<, <}, and b an integer. 

Parameters There is a first parameter that represents a list of k dictionar- 
ies representing each product in the sum. Each dictionary contains an integer 
coefficient (associated with the coef key) and one variable identifier (associ- 
ated with the var key) . The conventional order of keys in these dictionaries is 
coef ,var. Therefore, {/coef 2 /var XI} can be represented as {2 XI}. 

There is a second parameter which is a tag denoting the relational operator. 
It corresponds to an atom that must necessarily belong to {<eq/> , <ne/> , <ge/>, 
<gt/>,<le/>,<lt/>} (see Table [lj. There is a third parameter which is an 
integer. 

Example VO + 2V1 - 3V2 > 12 

<constraint name="C2" arity="3" scope="VO VI V2" ref erence="global : weightedSum"> 
<parameters> 

[ { 1 VO } { 2 VI } { -3 V2 } ] 

<gt/> 

12 

</parameters> 
</constraint> 

The syntax of the weightedSum global constraint slightly changed from the 
XCSP 2.0 format to the current format. The first parameter of this constraint 
is now a list of dictionaries (previously, it was a list of lists) . The old syntax is 
deprecated. 
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Alternatives This arithmetic constraint can be represented in intension 
(using the grammar described earlier in the paper). It is interesting to note 
that: 

• E[=i h * Xi = b E[=i ki * Xi > b A £[ =1 h*X t <b 

• ELi ki*Xi^b& E[=i &i * X > 6 V ELi ki*Xi<b 

• E[=i h*x t >b^ YH=i k*Xi>b-i 

• E[=i fe* * < 6 <*=> E[=i * > -6 



References This arithmetic constraint is related to the constraint called 
sum_ctr in [5] . Some information can also be found in |14j . 



3.6.4 Global constraints from the Catalog 



The catalog of global constraints (see http://www.emn.fr/x-info/sdemasse/ 



gecat) describes a huge number of global constraints. This section describes 
how these constraints can be translated in the XML representation. This de- 
scription is based on the 2006-09-30 version of the catalog. 

This version of the XML format supports global constraints from the cat- 
alog with parameters of type int, dvar, list and collection (in the catalog 
terminology) . 

Unless stated otherwise for a particular constraint, the name of the global 
constraint in the XML representation is directly obtained from the name of the 
constraint in the catalog by prefixing it with 'global:'. For example, the catalog 
defines a constraint named cumulative. In the XML representation, it is named 
global: cumulative. The semantics of the global constraint is the one defined 
in the catalog. 

Except for some particular cases, parameters of global constraints are rep- 
resented according to the following rules. 

atom In the catalog, a parameter of type atom is represented in the XML format 
by a tag. Atoms representing relational operators will be denoted by 
elements of {<eq/> , <ne/> , <ge/>, <gt/> , <le/> , <lt/>} (see Table [I). 

int In the catalog, a parameter of type int is an integer constant. It is 
represented in the XML format as an integer constant (<i>value</i> in 
tagged notation or value in abridged notation) . 

dvar In the catalog, a parameter of type dvar corresponds to a CSP vari- 
able. It is represented in the XML format as a variable reference (<var 
name="X"/> in tagged notation or X in abridged notation). A parameter 
of type dvar can also correspond to an integer constant. 



list A list of elements in the catalog of global constraints is represented as a 
list in the XML format (cf. [2~7| . 



3 REPRESENTING CSP INSTANCES 



24 



collection The catalog defines a collection as a collection of ordered items, each item 
being a set of <attribute , value > pairs. In our XML representation, this 
is directly translated as a list of dictionaries. The keys in each dictionary 
correspond to the attributes in the collection. 

As an example, the cumulative constraint is defined in the catalog as 
cumulative (TASKS; LIMIT) where TASKS is a collection(origin-dvar; 
duration-dvar; end-dvar; hcight-dvar) and LIMIT is an int. For each 
task, height must be defined but only two attributes among origin, du- 
ration and end can be defined (since by definition origin-end=duration) . 
A constraint that enforces a maximal height of 4 for 3 tasks starting at 
origins represented as a CSP variable and with given duration and height, 
can be represented by: 

Constraint name="Cl" arity="3" scope="X2 X5 X9" ref erence="global : cumulative"> 
<parameters> 
[ 

{/origin X2 /duration 10 /height 1} 
{/origin X5 /duration 5 /height 2} 
{/origin X9 /duration 8 /height 3} 

] 

4 

</parameters> 
</contraint> 

Note that attributes that are not required are represented as missing keys 
in the dictionaries. 

Assuming the conventional order origin, duration, end, height is defined 
for cumulative, this constraint can also be written as 

Constraint name="Cl" arity="3" scope="X2 X5 X9" ref erence="global : cumulative"> 
<parameters> 
[ 

{X2 10 <nil/> 1} 
{X5 5 <nil/> 2} 
{X9 8 <nil/> 3} 

] 

4 

</parameter s> 
</contraint> 

Here, missing attributes are represented by the <nil/> element. 

For each global constraint, the conventional order of dictionaries is the 
order of attributes defined in the global catalog. 

When a global constraint has a collection parameter which contains only 
one attribute, it is represented as a list of values. For example, the 
global_cardinality constraint has a first parameter of type collection 
of dvar. It is represented directly a list of variables ( [XI X2 X3] ) instead 
of a list of dictionaries with one single key ( [{/var XI} {/var X2} {/var 
X3}] or, using conventional order, [{XI} {X2} {X3}]). 
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Arguments of a global constraint in the catalog must be translated in XML 
as a sequence of elements inside the tag <parameters> in the order defined in 
the catalog. 

Below, we present the description of some translations of global constraints 
from the catalog. Note that most of the global constraints from the catalog can 
be automatically translated in format XCSP 2.1. 

Constraint allDifferent It is defined in the catalog as follows: 

alldif f erent (VARIABLES ) 
VARIABLES collection (var:dvar) 

Following rules given above, we may have in XML: 

<constraint name="Cl" arity="4" scope="Vl V2 V3 V4" ref erence="global : allDifferent "> 

<parameters> 

[ VI V2 V3 V4 ] 

</parameters> 
</constraint> 

Note that it is also possible to include integer constants. For example: 

<constraint name="Cl" arity="4" scope="Vl V2 V3 V4" ref erence="global : allDifferent "> 

<parameters> 

[ VI V2 100 V3 V4 ] 

</parameters> 
</constraint> 

Note that the old syntax, with implicit parameters, is deprecated. On the 
other hand, this constraint can be represented in intension by introducing a 
predicate that represents a conjunction of inequalities. It can also be converted 
into a clique of binary notEqual constraints. For more information about this 
constraint, see e.g. [T31 ITT1 12"]. 

Constraint among It is defined in the catalog as follows: 

among ( NVAR , VARIABLES , VALUES ) 

NVAR dvar 

VARIABLES collection (var :dvar) 

VALUES collection(val:int) 

Following rules given above, as an illustration, we can have in XML: 

<constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" ref erence="global : among"> 
<parameters> 
V0 

[ VI V2 V3 V4 ] 
[ 1 5 8 10 ] 
</parameters> 
</constraint> 
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Constraint atleast It is defined in the catalog as follows: 

atleast (N , VARIABLES , VALUE) 
N int 

VARIABLES collection(var : dvar) 
VALUE int 

Following rules given above, we can have in XML: 

Constraint name="Cl" arity="4" scope="Vl V2 V3 V4" reference="global:atleast"> 
<parameters> 
1 

[ VI V2 V3 V4 ] 

2 

</parameters> 
</ constraint> 

Constraint atmost It is defined in the catalog as follows: 

atmost (N , VARIABLES , VALUE) 
N int 

VARIABLES collection(var : dvar) 
VALUE int 

Following rules given above, we can have in XML: 

<constraint name="Cl" arity="4" scope="Vl V2 V3 V4" reference="global:atmost"> 
<parameters> 
1 

[ VI V2 V3 V4 ] 

2 

</parameters> 
</constraint> 

Constraint cumulative It is defined in the catalog as follows: 

cumulative (TASKS , LIMIT) 

TASKS collection(origin:dvar, duration: dvar, end:dvar, height:dvar) 

LIMIT int 

Here, we have a collection of ordered items where each item corresponds to a 
task with 4 attributes (origin, duration, end and height), and a limit value. As 
an illustration, we can have in XML: 

Constraint name="Cl" arity="8" scope="01 Dl El HI 02 D2 E2 H2" 
ref erence= "global : cumulative "> 
<parameters> 

[ { 01 Dl El HI } { 02 D2 E2 H2 } ] 
8 

</parameters> 
</constraint> 
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As indicated in the constraint restrictions, one attribute among {origin, 
duration, end} may be missing. Assume that it is the case for end, we could 
have: 

Constraint name="Cl" arity="6" scope="01 Dl HI 02 D2 H2" 
ref erence= "global : cumulative "> 
<parameters> 

[ { 01 Dl <nil/> HI } { 02 D2 <nil/> H2 } ] 
8 

</parameters> 
</ constraint> 

Constraint cycle It is defined in the catalog as follows: 

cycle (NCYCLE, NODES) 
NCYCLE dvar 

NODES collection (index : int , succ:dvar) 

Here, we have a value that denotes a number of cycles and a collection of ordered 
items where each item consists of 2 attributes (index, succ). As an illustration, 
we can have in XML: 

Constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" ref erence="global : cycle"> 
<parameters> 
VO 

[ {1 VI} {2 V2} {3 V3} {4 V4} ] 
</parameters> 
</constraint> 

Constraint diffn It is defined in the catalog as follows: 

diffn(ORTHOTOPES) 

0RTH0T0PES collection(orth:0RTH0T0PE) 

0RTH0T0PE collection (origin: dvar , size: dvar, end: dvar) 

As an illustration, we can have in XML: 

Constraint name="Cl" arity="18" scope="V0 VI V2 V3 V4 V5 V6 V7 V8 V9 V10 
Vll V12 V13 V14 V15 V16 V17" ref erence="global : diffn" > 
<parameters> 
[ 

[ {VO VI V2} {V3 V4 V5} ] 

[ {V6 V7 V8} {V9 V10 Vll} ] 

[ {V12 V13 V14} {V15 V16 V17} ] 

] 

</parameters> 
</ constraint> 
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Constraint disjunctive It is defined in the catalog as follows: 

disjunctive (TASKS) 

TASKS collection (origin :dvar, duration :dvar) 

Here, we have a collection of ordered items where each item corresponds to a 
task with 2 attributes (origin, duration). As an illustration, we can have in 
XML: 

Constraint name="Cl" arity="6" scope="01 Dl 02 D2 03 D3" ref erence="global :disjunctive"> 

<parameters> 

[ { 01 Dl} {02 D2} {03 D3} ] 

</parameters> 
</constraint> 

Constraint element It is defined in the catalog as follows: 

element (INDEX , TABLE , VALUE) 
INDEX dvar 

TABLE collection(value:dvar) 
VALUE dvar 

As an illustration, we can have in XML: 

Constraint name="Cl" arity="5" scope="I XI X2 X3 V" ref erence="global : element "> 
<parameters> 
I 

[ XI X2 X3 ] 
V 

</parameters> 
</constraint> 

Constraint globaLcardinality It is defined in the catalog as follows: 

global.cardinality (VARIABLES, VALUES) 

VARIABLES collection(var :dvar) 

VALUES collection(val : int , noccurrence:dvar) 

As an illustration, we can have in XML: 

Constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" 
ref erence="global : global_cardinality"> 
<parameters> 

[ V0 VI V2 ] 
[ { 1 V3 } { 2 V4 } ] 
</parameters> 
</constraint> 
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Constraint global_cardinality_with_costs It is defined as follows: 

global_cardinality_with_costs (VARIABLES .VALUES , MATRIX , COST) 

VARIABLES collection (var:dvar) 
VALUES collection(val : int , noccurrence:dvar) 
MATRIX collectiond : int , j : int , c:int) 
COST dvar 

As an illustration, we can have in XML: 

Constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" 

ref erence="global : global_cardinality_with_costs"> 
<parameters> 

[ VO VI V2 ] 

[ { 1 V3 } { 2 V4 } ] 

[ {1 1 1} {1 1 0} {1 1 3} {1 1 2} {1 1 4} {1 1 2} ] 
V5 

</parameters> 
</ constraint> 



Constraint minimum weight all different It is denned as follows: 

minimum_weight_alldif f erent (VARIABLES .MATRIX , COST) 

VARIABLES collection (var :dvar) 

MATRIX collectiond : int , j:int, c:int) 

COST dvar 

As an illustration, we can have in XML: 

<constraint name="Cl" scope="V0 VI V2 V3" ref erence="global:minimum_weight_all_diff erent"> 
<parameters> 

[ VO VI V2 ] 

[ {1 1 1} {1 1 0} {1 1 3} {1 1 2} {1 1 4} {1 1 2} ] 
V3 

</parameters> 
</ constraint> 

Constraint not_all_equal It is defined in the catalog as follows: 

not_all_equal (VARIABLES) 
VARIABLES collection (var : dvar) 

As an illustration, we can have in XML: 

Constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" ref erence="global :not_all_equal"> 

<parameters> 

[ VO VI V2 V3 V4 ] 

</parameters> 
</constraint> 
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Constraint nvalue It is defined in the catalog as follows: 

nvalue (NVAL , VARIABLES) 

NVAL dvar 

VARIABLES collection (var :var) 

As an illustration, we can have in XML: 

<constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" ref erence="global :nvalue"> 
<parameters> 
VO 

[ VI V2 V3 V4 ] 
</parameters> 
</constraint> 

Constraint nvalues It is defined in the catalog as follows: 

nvalues (VARIABLES , RELQP .LIMIT) 

VARIABLES collection (var : dvar) 
RELOP atom 
LIMIT dvar 

RELOP in {eq,ne ,ge ,gt ,le, It} 

As an illustration, we can have in XML: 

<constraint name="Cl" arity="5" scope="V0 VI V2 V3 V4" ref erence="global :nvalues"> 
<parameters> 

[ VI V2 V3 V4 ] 

<gt/> 

VO 

</parameters> 
</constraint> 

3.7 Illustrations 

In Figures [2] and [3] one can see the XML representation of the 4-queens instance. 
In Figures |4j [5] and [6] one can see the XML representation of a CSP instance 
involving 5 variables and the 5 following constraints: 

• CO: X0 ^ XI 

• CI: X'i — AO > 2 

• C2: X2-X0 = 2 

• d: Xl+2= \X2-X3\ 

• C4: XI ^ XA 

Finally, in Figures [7] and |8] one can see the XML representation of the 3- 
magic square instance. The global constraints weightedSum and allDif ferent 
are used. 
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4 Representing QCSP instances 

This is a proposal for QCSP and QCSP+ by M. Benedetti, A. Lallouet and 
J. Vautard. 

The Quantified Constraint Satisfaction Problem (QCSP) is an extension of 
CSP in which variables may be quantified universally or existentially. A QCSP 
instance corresponds to a sequence of quantified variables, called prefix, followed 
by a conjunction of constraints. QCSP and its semantics were introduced in [5]. 
QCSP + is an extension of QCSP, introduced in [3] to overcome some difficulties 
that may occur when modelling real problems with classical QCSP. From a logic 
viewpoint, an instance of QCSP+ is a formula in which (i) quantification scopes 
of alternate type are nested one inside the other, (ii) the quantification in each 
scope is restricted by a CSP called restriction or precondition, and (iii) a CSP 
to be satisfied, called goal, is attached to the innermost scope. An example with 
4 scopes is: 



yx 1 (l?(Xi)-> 

3Yi (Lf(Xi,yi)A 

VX 2 (I? 2 (X 1 ,Y 1 ,X 2 )^ 

3Y 2 (Lj(X 1 ,Y 1 ,X 2 ,Y 2 )A G(X 1 ,X 2 ,Y 1 ,Y 2 )) 

) 

) 

) (1) 

where Xi, X 2 , Y%, and Y\ are in general sets of variables, and each Lf is a 
conjunction of constraints. A more compact and readable syntax for QCSP + 
employs square braces to enclose restrictions. An example with 3 scopes is as 
follows 



yX 1 [L v 1 (X 1 )} 3Y 1 [Lf(X 1 ,Y 1 )} \/X 2 [Ll{X u Y x ,X 2 )\ G{X 1 ,Y U X 2 ) 

which reads "for all values of Xi which satisfy the constraints L\(Xx), there 
exists a value for Y\ that satisfies Lf(Xi, Y\) and is such that for all values for 
X 2 which satisfy L\(X 1 ,Y 1 ,X 2 ), the goal G(X 1 ,X 2 ,Y 1 ) is satisfied". 

A standard QCSP can be viewed as a particular case of QCSP + in which all 
quantifications are unrestricted, i.e. all the CPSs Lf are empty. 



4.1 Presentation 

With respect to format XCSP 2.0, here is the extension to the XML element 
called <presentation> in order to deal with a QCSP instance: 

• the attribute format must be given the value "XCSP 2.1". 

• the attribute type is required and its value must be "QCSP" or "QCSP+". 
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All the relevant information on quantification in included in a new section 
called "quantification" (see below). 

4.2 Quantification 

This section gives the quantification structure associated with a QCSP/QCSP+ 
instance. It essentially provides an ordered list of quantification blocks, called 
blocks. The size of this list is mandatorily declared in the attribute nbBlocks: 

<quantif ication nbBlocks="b"> 

put here a sequence of b blocks 
</quantif ication> 

Notice that the order in which quantification blocks are listed inside this 
XML element provides key information, as it specifies the left-to-right order of 
(restricted) quantifications associated with the QCSP/QCSP + instance. Each 
block of a QCSP/QCSP + instance is represented by the following XML element: 

<block quantifier = 'put here the quantifier type' 
scope = 'put here a list of variable names '> 

put here an optional list of constraints (QCSP+ only) 
</block> 

where 

• the value of the attribute quantifier must be either "exists" or "forall" . 
It gives the kind of quantification of all the variables in this block; 

• the value of the attribute scope specifies the variables which are quantified 
in this block. At least one variable must be present. The order in which 
variables are listed is not relevant; 

• for QCSP instances, the body of a block element must be empty 

• for QCSP+ instances, the body of the block element may contain one or 
more <constraint> elements that restrict the quantification of the block 
to the sole values of the quantified variables which satisfy all constraints 
defined in the body of the <block> element. 

Such constraints may only refer to variables defined in the same block 
and to variables defined in previous blocks (w.r.t. to the order in the 
enclosing <quantif ication> clement), but not to variables mentioned in 
later blocks; 

Notice the following features of well-formed QCSP/QCSP+ instances: 

1. each variable can be mentioned in at most one block; 

2. each variable must be mentioned in at least one block; this means the 
problem is closed, i.e. no free variables are allowecj^] 

2 This restriction may be relaxed by future formalizations of open QCSPs. 
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4.3 Illustrations 

Let the domain of all the variables we introduce be {1,2,3,4}. 

• An XML encoding of the QCSP: 

3W,X MY 3Z W + X = Y + Z, Y ^ Z 
is given in Figure [9] 

• An XML encoding of the QCSP+: 

3W, X[W+X < 8, W-X > 2] MY [W Y, X / Y] 3Z[Z < W-Y] W+X = Y+Z 
is given in Figure [TO) 

5 Representing WCSP instances 

The classical CSP framework can be extended by associating weights (or costs) 
with tuples [4]. The WCSP (Weighted CSP) is a specific extension that rely on 
a specific valuation structure S(k) defined as follows. 

Definition 1 S(k) is a triple ([0, . . . , k), 0, >) where: 

k G [1, . . . , oo] is either a strictly positive natural or infinity, 

[0,1,..., k] is the set of naturals less than or equal to k, 

© is the sum over the valuation structure defined as: a® b = min{k, a + b} ; 

> is the standard order among naturals. 

A WCSP instance is defined by a valuation structure S(k), a set of variables 
(as for classical CSP instances) and a set of constraints. A domain is associated 
with each variable and a cost function with each constraint. More precisely, for 
each constraint C and each tuple t that can be built from the domains associated 
with the variables involved in C, a value in [0,1,..., k] is assigned to t. When a 
constraint C assigns the cost k to a tuple t, it means that C forbids t. Otherwise, 
t is permitted by C with the corresponding cost. The cost of an instantiation of 
variables is the sum (using operator ©) over all constraints involving variables 
instantiated. An instantiation is consistent if its cost is strictly less than k. The 
goal of the WCSP problem is to find a full consistent assignment of variables 
with minimum cost. 

It is rather easy to represent WCSP in XML in format XCSP 2.1. This is 
described below. 

5.1 Presentation 

Here are the extensions to the XML element called <presentation> in order 
to deal with a WCSP instance: 

• the attribute format must be given the value "XCSP 2.1". 

• the attribute type is required and its value must be "WCSP". 
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5.2 Relations 

For WCSP represented in extension, it is necessary to introduce "soft" relations. 
These relations are defined as follows: 



the value of the attribute semantics is set to "soft". 



weighted tuples are given as described in Section 2.11 



an new attribute defaultCost is mandatory and represents the cost of 
any tuple which is not explicitly listed in the relation. Its value belongs to 
[0, . . . , k] where k is the maximal cost of the valuation structure, defined by 
the attribute maximalCost of the element <constraints> (see below). 
Note that it may be the special value 'infinity'. 



5.3 Functions 

Instead of representing constraints of a WCSP in extension, it is possible to rep- 
resent them in intension by introducing cost functions. For any tuple passed to 
such a function, its cost is computed and returned. In other words, we employ 
here exactly the same mechanism as the one employed for hard constraints rep- 
resented in intension. The only difference is that a predicate returns a Boolean 
value whereas a cost function must return an integer value. 

If present, the XML element called <functions> admits an attribute which 
is called nb Functions and contains some occurrences (at least, one) of an 
element called <function>, one for each function associated with at least a 
constraint of the instance. The attribute nbFunctions is of type integer and 
its value is equal to the number of occurrences of the element <f unction>. The 
<functions> clement must be a direct child of the <instance> element. 

Each element <function> admits two attributes, called name and return, 
and contains two elements, called <parameters> and <expression>. It is de- 
fined as follows: 



<function name = 'put here the name of the function 3 return= ' return type'> 
<parameters> 

put here a list of formal parameters 
</parameters> 
<expression> 

Put here one (or several) representation(s) of the function expression 
</expression> 
</f unction> 



The attribute name corresponds to the name of the function and its value 
must be a valid identifier. 

The attribute return indicates the return type of the function. In this ver- 
sion of the format, the only return type used is 'int'. Then elements <parameters> 
and <expression> are defined exactly as those defined for <predicate> el- 
ements. The only difference is that the expression must be of type integer 
instead of being of type Boolean. 
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5.4 Constraints 

For any WCSP instance, it is required to introduce an attribute maximalCost 
to the element <constraints>. The value of this attribute is of type integer 
(and must be strictly positive) and represents the maximum cost of the WCSP 
framework (the k value). Remember that it corresponds to a total violation and 
may be equal to 'infinity' (whereas corresponds to a total satisfaction). Also, 
an optional attribute initialCost to the element <constraints> is introduced. 
If present, the value of this attribute is of type integer and represents a constant 
cost that must be added to the sum of constraints cost. This is the cost of the 
0-ary constraint of the WCSP framework which is sometimes assumed (e.g. see 
[T^]). When not present, it is assumed to be equal to 0. 

Remark 2 When representing a WCSP instance, it is possible to refer to hard 
constraints (defined in extension or intension). For such constraints, an allowed 
tuple has a cost of while a disallowed tuple has a cost equal to the value of the 
attribute maximalCost. 

5.5 Illustration 

The representation in XCSP 2.1 of an illustrative WCSP instance is given by 
Figure [12] 
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<instance> 

presentation name=" Queens" nbSolutions="at least 1" format="XCSP 2.1"> 

This is the 4-queens instance represnted in extension. 
</presentation> 

<domains nbDomains= " 1 " > 

<domain name="D0" nbValues="4"> 
1. .4 

</domain> 
</domains> 

<variables nbVariables="4"> 

<variable name="VO" domain="D0"/> 

<variable name="Vl" domain="D0"/> 

<variable name="V2" domain="D0"/> 

<variable name="V3" domain="D0"/> 
</variables> 

<relations nbRelations="3"> 

<relation name="RO" arity="2" nbTuples=" 10" semantics="conf licts"> 

1 111 2|2 1|2 2|2 3|3 2 I 3 3 1 3 4|4 3 I 4 4 
</relation> 

<relation name="Rl" arity="2" nbTuples="8" semantics="conf licts"> 

1 111 3|2 2|2 4|3 1|3 3 1 4 2 1 4 4 
</relation> 

<relation name="R2" arity="2" nbTuples="6" semantics="conf licts"> 

1 111 4|2 2|3 3|4 1|4 4 
</relation> 
</relations> 

<constraints nbConstraints="6"> 

<constraint name="C0" arity="2" scope="V0 VI" ref erence="R0"/> 
<constraint name="Cl" arity="2" scope="V0 V2" ref erence="Rl"/> 
<constraint name="C2" arity="2" scope="V0 V3" ref erence="R2"/> 
<constraint name="C3" arity="2" scope="Vl V2" ref erence="R0"/> 
<constraint name="C4" arity="2" scope="Vl V3" ref erence="Rl"/> 
<constraint name="C5" arity="2" scope="V2 V3" ref erence="R0"/> 

</constraints> 
</instance> 



Figure 2: The 4-queens instance in extension 
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<instance> 

<presentation name=" Queens" nbSolutions="at least 1" f ormat="XCSP 2.1"> 
This is the 4-queens instance represented in intention. 
</presentation> 



<domains nbDomains="l"> 

<domain name="DO" nbValues="4"> 
1. .4 

</domain> 
</domains> 



<variables nbVariables="4"> 

<variable name="VO" domain="DO"/> 
<variable name="Vl" domain="DO"/> 
<variable name="V2" domain="DO"/> 
<variable name="V3" domain="DO"/> 

</variables> 



<predicates nbPredicates="l"> 
<predicate name="P0"> 

<parameters> int XO int XI int X2 </parameters> 
<expression> 

<functional> and(ne(XO,Xl) ,ne (abs (sub(XO.Xl) ) ,X2)) </f unctional> 
</expression> 
</predicate> 
</predicates> 

<constraints nbConstraints="6"> 

<constraint name="C0" arity="2" scope="VO VI" ref erence="PO"> 

<parameters> VO VI 1 </parameters> 
</constraint> 

<constraint name="Cl" arity="2" scope="V0 V2" ref erence="PO"> 

<parameters> VO V2 2 </parameters> 
</constraint> 

Constraint name="C2" arity="2" scope="V0 V3" ref erence="P0"> 

<parameters> VO V3 2 </parameters> 
</constraint> 

<constraint name="C3" arity="2" scope="Vl V2" ref erence="P0"> 

<parameters> VI V2 1 </parameters> 
</constraint> 

<constraint name="C4" arity="2" scope="Vl V3" ref erence="P0"> 

<parameters> VI V3 2 </parameters> 
</constraint> 

<constraint name="C5" arity="2" scope="V2 V3" ref erence="P0"> 

<parameters> V2 V3 1 </parameters> 
</constraint> 
</constraints> 
</instance> 



Figure 3: The ^-queens instance in intention 
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<instance> 

presentation name="Test" format="XCSP 2.1"> 

This is another instance represented in extension. 
</presentation> 

<domains nbDomains= " 3 " > 

<domain name="DO" nbValues="7"> 

0. .6 
</domain> 

<domain name="Dl" nbValues="3"> 

1 5 10 
</domain> 

<domain name="D2" nbValues="10"> 

1. .5 11. .15 
</domain> 
</domains> 

<variables nbVariables="5"> 

<variable name="V0" domain="D0"/> 

<variable name="Vl" domain="D0"/> 

<variable name="V2" domain="Dl"/> 

<variable name="V3" domain="D2"/> 

<variable name="V4" domain="D0"/> 
</variables> 

<relations nbRelations="4"> 

<relation name="R0" arity="2" nbTuples="7" semantics="conf licts"> 

Oil 1|2 2|3 3|4 4|5 5 1 6 6 
</relation> 

<relation name="Rl" arity="2" nbTuples="25" semantics="conf licts"> 

1 Oil 111 2 1 1 3|1 4 1 1 5 1 1 6|2 1|2 2 I 2 3 I 2 4 I 2 5 ] 2 6 I 3 2 I 3 3| 
3 4|3 5|3 6|4 3|4 4 I 4 5|4 6 I 5 4|5 5 I 5 6 

</relation> 

<relation name="R2" arity="2" nbTuples="l" semantics="supports"> 

5 3 
</relation> 

<relation name="R3" arity="3" nbTuples=" 17" semantics="supports"> 
1 3|0 5 3|0 10 12|1 1 4 1 1 5 2 1 1 10 13 1 2 1 5 1 2 5 1 1 2 10 14 1 
3 10 5 I 3 10 15|4 5 11 1 4 10 4 1 5 5 12 I 5 10 3 I 6 5 13 I 6 10 2 

</relation> 
</relations> 

Constraints nbConstraints="5"> 

Constraint name="C0" arity="2" scope="V0 VI" ref erence="R0"/> 
Constraint name="Cl" arity="2" scope="V3 VO" ref erence="Rl"/> 
Constraint name="C2" arity="2" scope="V2 VO" ref erence="R2"/> 
Constraint name="C3" arity="3" scope="Vl V2 V3" ref erence="R3"/> 
<constraint name="C4" arity="2" scope="Vl V4" ref erence="R0"/> 

</constraints> 
</instance> 



Figure 4: Test Instance in extension 
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<instance> 

presentation name="Test" f ormat="XCSP 2.1"> 

This is another instance represented in intention. 
</presentation> 

<domains nbDomains= " 3 " > 

<domain name="domO" nbValues="7"> 

0. .6 
</domain> 

<domain name="doml" nbValues="3"> 

1 5 10 
</domain> 

<domain name="dom2" nbValues="10"> 

1. .5 11. .15 
</domain> 
</domains> 

<variables nbVariables="5"> 

<variable name="V0" domain="dom0"/> 

<variable name="Vl" domain="dom0"/> 

<variable name="V2" domain="doml"/> 

<variable name="V3" domain="dom2"/> 

<variable name="V4" domain="dom0"/> 
</variables> 

<predicates nbPredicates="4"> 
<predicate name="P0"> 

<parameters> int X0 int XI </parameters> 

<expression> 

<functional> ne(X0,Xl) </f unctional> 

</expression> 
</predicate> 
<predicate name="Pl"> 

<parameters> int X0 int XI int X2 </parameters> 

<expression> 

<functional> ge(sub(X0,Xl) ,X2) </f unctional> 

</expression> 
</predicate> 
<predicate name="P2"> 

<parameters> int X0 int XI int X2 </parameters> 

<expression> 

<functional> eq(sub(X0,Xl) ,X2) </f unctional> 

</expression> 
</predicate> 
<predicate name="P3"> 

<parameters> int X0 int XI int X2 int X3 </parameters> 

<expression> 

<functional> eq(add(X0 ,X1) , abs (sub(X3,X4) ) ) </f unctional> 
</expression> 
</predicate> 
</predicates> 



Figure 5: Test Instance in intention (to be continued) 
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Constraints nbConstraints="5"> 

<constraint name="C0" arity="2" scope="VO VI" ref erence="PO"> 

<parameters> VO VI </parameters> 
</constraint> 

<constraint name="Cl" arity="2" scope="VO V3" ref erence="Pl"> 

<parameters> V3 VO 2 </parameters> 
</constraint> 

<constraint name="C2" arity="2" scope="VO V2" ref erence="P2"> 

<parameters> V2 VO 2 </parameters> 
</constraint> 

<constraint name="C3" arity="3" scope="Vl V2 V3" ref erence="P3' 

<parameters> VI 2 V2 V3 </parameters> 
</constraint> 

<constraint name="C4" arity="2" scope="Vl V4" ref erence="P0"> 

<parameters> VI V4 </parameters> 
</constraint> 
</constraints> 
</instance> 



Figure 6: Test Instance in intention (continued) 



REFERENCES 



42 



<instance> 

presentation name="Magic Square" format="XCSP 2.1"> 

This is the magic square of order 3. 
</presentation> 

<domains nbDomains= " 1 " > 

<domain name="domO" nbValues="9"> 
1. .9 

</domain> 
</domains> 



<variables nbVariables="9"> 



<variable 


name= 


"XO" 


domain= 


"domO"/> 


<variable 


name= 


"XI" 


domain= 


"domO"/> 


<variable 


name= 


"X2" 


domain= 


"domO"/> 


<variable 


name= 


"X3" 


domain= 


"domO"/> 


<variable 


name= 


"X4" 


domain= 


"domO"/> 


<variable 


name= 


"X5" 


domain= 


"domO"/> 


<variable 


name= 


"X6" 


domain= 


"domO"/> 


<variable 


name= 


"X7" 


domain= 


"domO"/> 


<variable 


name= 


"X8" 


domain= 


"domO"/> 



</variables> 



<constraints nbConstraints="8"> 

Constraint name="CO" arity="3" scope="X0 XI X2" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 XO } { 1 XI } { 1 X2 } ] 

<eq/> 

15 

</parameters> 
</constraint> 

<constraint name="Cl" arity="3" scope="X3 X4 X5" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 X3 } { 1 X4 } { 1 X5 } ] 

<eq/> 

15 

</parameters> 
</constraint> 

<constraint name="C2" arity="3" scope="X6 X7 X8" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 X6 } { 1 X7 } { 1 X8 } ] 
<eq/> 
15 

</parameters> 
</constraint> 

<constraint name="C3" arity="3" scope="X0 X3 X6" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 XO } { 1 X3 } { 1 X6 } ] 

<eq/> 

15 

</parameters> 
</constraint> 



Figure 7: The 3-magic square instance (to be continued) 
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<constraint name="C4" arity="3" scope="Xl X4 X7" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 XI } { 1 X4 } { 1 X7 } ] 

<eq/> 

15 

</parameters> 
</constraint> 

<constraint name="C5" arity="3" scope="X2 X5 X8" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 X2 } { 1 X5 } { 1 X8 } ] 

<eq/> 

15 

</parameters> 
</constraint> 

<constraint name="C6" arity="3" scope="XO X4 X8" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 XO } { 1 X4 } { 1 X8 } ] 

<eq/> 

15 

</parameters> 
</constraint> 

<constraint name="C7" arity="3" scope="X2 X4 X6" ref erence="global :weightedSum"> 
<parameters> 

[ { 1 X2 } { 1 X4 } { 1 X6 } ] 

<eq/> 

15 

</parameters> 
</constraint> 

<constraint name="C8" arity="9" scope="X0 XI X2 X3 X4 X5 X6 X7 X8" 
ref erence="global : allDlf f erent " /> 

</constraints> 
</instance> 



Figure 8: The 3-magic square instance (continued) 
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<instance> 

presentation name="ExampleQCSP" f ormat="XCSP 2.1" type="QCSP"> 

This is a QCSP instance. 
</presentation> 

<domains nbDomains= " 1 " > 

<domain name="DO" nbValues="4"> 
1. .4 

</domain> 
</domains> 

<variables nbVariables="4" > 

<variable name="W" domain="DO"/> 

<variable name="X" domain="DO"/> 

<variable name="Y" domain="DO"/> 

<variable name="Z" domain="DO"/> 
</variables> 

<predicates nbPredicates="2"> 
<predicate name="P0"> 

<parameters> int A int B int C int D </parameters> 
<expression> 

<functional> eq(add(A,B) , add(C ,D) ) </f unctional> 

</expression> 
</predicate> 
<predicate name="Pl"> 

<parameters> int A int B </parameters> 

<expression> 

<functional> ne(A,B) </f unctional> 

</expression> 
</predicate> 
</predicates> 

<constraints nbConstraints="2"> 

Constraint name="C0" arity="4" scope="W X Y Z" ref erence="P0"> 

<parameters> W X Y Z </parameters> 
</constraint> 

<constraint name="Cl" arity="2" scope="Y Z" ref erence="Pl"> 

<parameters> Y Z </parameters> 
</constraint> 
</constraints> 

<quantif ication nbBlocks="3"> 

<block quantif ier="exists" scope="W X" \> 
<block quantif ier="forall" scope="Y" \> 
<block quantif ier="exists" scope="Z" \> 
</quantif ication > 
</instance> 



Figure 9: A QCSP instance 
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<instance> 

presentation name="ExampleQCSP+" f ormat="XCSP 2.1" type="QCSP+"> 

This is a QCSP+ instance. 
</presentation> 

<domains nbDomains= " 1 " > 

<domain name="D0" nbValues="4"> 
1. .4 

</domain> 
</domains> 

<variables nbVariables="4" > 

<variable name="W" domain="DO"/> 

<variable name="X" domain="DO"/> 

<variable name="Y" domain="DO"/> 

<variable name="Z" domain="DO"/> 
</variables> 

<predicates nbPredicates="4"> 
<predicate name="myP"> 

<parameters> int A int B int C int D </parameters> 
<expression> 

<functional> eq(add(A,B) , add(C,D) ) </f unctional> 
</expression> 
</predicate> 

<predicate name="sum_lt"> 

<parameters> int A int B int C</parameters> 

<expression> 

<functional> It (add(A,B) , C) </f unctional> 

</expression> 
</predicate> 

<predicate name="sub_gt"> 

<parameters> int A int B int C</parameters> 
<expression> 

<functional> gt(sub(A,B) , C) </f unctional> 
</expression> 
</predicate> 
<predicate name="neq"> 

<parameters> int A int B</parameters> 
<expression> 

<f unctional> ne (A,B) </f unctional> 
</expression> 
</predicate> 
</predicates> 



Figure 10: A QCSP + instance (to be continued) 
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Constraints nbConstraints="l"> 

<constraint name="goal" arity="4" scope="W X Y Z" ref erence="myP"> 
<parameters> W X Y Z </parameters> 

</constraint> 
</constraints> 

<quantif ication nbBlocks="3"> 

<block quantif ier="exists" scope="W X"> 

Constraint name="restrl_cl" arity="2" scope="W X" ref erence="sum_lt"> 

<parameters> W X 8 </parameters> 
</constraint> 

<constraint name="restrl_c2" arity="2" scope="W X" ref erence="sub_gt"> 

<parameters> W X 2 </parameters> 
</constraint> 
</block> 

<block quantif ier= "universal" scope="Y"> 

<constraint name="restr2_cl" arity="2" scope="W Y" ref erence="neq"> 

<parameters> W Y </parameters> 
</constraint> 

<constraint name="restr2_c2" arity="2" scope="X Y" ref erence="neq"> 

<parameters> X Y </parameters> 
</constraint> 
</block> 

<block quantif ier="existential" scope="Z"> 

<constraint name="restr3_cl" arity="3" scope="W Y Z" ref erence="sub_gt" 

<parameters> W Y Z </parameters> 
</constraint> 
</block> 
</quantif ication > 
</instance> 



Figure 11: A QCSP+ instance (continued) 
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<instance> 

presentation name="ExampleWCSP" f ormat="XCSP 2.1" type="WCSP"> 

This is a WCSP instance. 
</presentation> 

<domains nbDomains= " 1 " > 

<domain name="DO" nbValues="3">0 . . 2</domain> 
</domains> 



<variables nbVariables="4"> 

<variable name="VO" domain="DO"/> 
<variable name="Vl" domain="DO"/> 
<variable name="V2" domain="D0"/> 
<variable name="V3" domain="D0"/> 

</variables> 



<relations nbRelations="6"> 

<relation name="RO" arity="2" nbTuples=" 10" semantics="sof t" def aultCost="0"> 

5:0 0|0 111 Oil 111 2|2 1|2 2 I 2 3 I 3 2 I 3 3 
</relation> 

<relation name="Rl" arity="l" nbTuples="2" semantics="sof t" def aultCost="0"> 

1:113 
</relation> 

<relation name="R2" arity="l" nbTuples="2" semantics="sof t" def aultCost="0"> 

1:112 
</relation> 

<relation name="R3" arity="l" nbTuples="2" semantics="sof t" def aultCost="0"> 

1:012 
</relation> 
</relations> 

<functions nbFunctions="2"> 

<function name="F0" return="int"> 

<parameters> int X int Y </parameters> 
<expression> 

<functional> if (eq(X, Y) , , 5) </f unctional> 
</expression> 
</f unction> 

<function name="Fl" return="int"> 

<parameters> int X int Y int Z </parameters> 
<expression> 

<functional> if (gt(mul(add(X,Y) ,Z) ,5) ,0,2) </f unctional> 
</expression> 
</f unction> 
</f unctions> 



Constraints nbConstraints="7" initialCost="0" maximalCost="5"> 
<constraint name="C0" arity="2" scope="V0 VI" ref erence="R0" /> 
Constraint name="Cl" arity="2" scope="V0 V2" ref erence="F0 /> 
<constraint name="C2" arity="3" scope="Vl V2 V3" ref erence="Fl" /> 
Constraint name="C3" arity="l" scope="V0" ref erence="Rl" /> 
Constraint name="C4" arity="l" scope="Vl" ref erence="R2" /> 
<constraint name="C5" arity="l" scope="V2" ref erence="R3" /> 

</constraints> 
</instance> 



Figure 12: A WCSP instance 



